Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#9588: Add support to multi-band color mapping for COG layers #9857

Merged
merged 11 commits into from
Mar 21, 2024

Conversation

dsuren1
Copy link
Contributor

@dsuren1 dsuren1 commented Jan 9, 2024

Description

This PR allows multi band color mapping of COG layers along modification of min and max source data value

Please check if the PR fulfills these requirements

What kind of change does this PR introduce? (check one with "x", remove the others)

  • Enhancement

Issue

What is the current behavior?

What is the new behavior?
image

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

  • Yes, and I documented them in migration notes
  • No

Other useful information

@dsuren1 dsuren1 added this to the 2023.02.02 milestone Jan 9, 2024
@dsuren1 dsuren1 requested a review from offtherailz January 9, 2024 13:09
@dsuren1 dsuren1 self-assigned this Jan 9, 2024
@dsuren1 dsuren1 linked an issue Jan 9, 2024 that may be closed by this pull request
6 tasks
@dsuren1
Copy link
Contributor Author

dsuren1 commented Jan 9, 2024

Looks like GitHub experiencing outage causing actions to fails
image

Copy link
Member

@offtherailz offtherailz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • information for bands and styling should be documented, or is not easy to understand if they are properly made to be compatible for future evolution. Note that style information should be compatible with a future expansion with multiple source (so store style and source information with this in mind). I'll ask to @dromagnoli some help understanding these parameters

For the moment here some bugs I found:

  • once changed, there is no way to restore max and min

    screencast-mail.google.com-2024.01.16-16_55_16.webm
  • Sometimes it switches to one band randomly

    screencast-mail.google.com-2024.01.16-17_03_21.webm

web/client/api/catalog/COG.js Outdated Show resolved Hide resolved
@offtherailz
Copy link
Member

offtherailz commented Jan 17, 2024

Hi, from a brief discussion about it with @dromagnoli I understood that
Samples count should be the samples count + sope possible extra samples

Ideally I'd transfer to the layer the information about the tiff as plain as possible to the layer metadata, so if there is some error in interpretation, we can fix the code and we don't have to fix the layer.

Theoretically even if data can suggest you the style to use, you may decide to show 1 gray scale, RGB or RGBA independently from the origial bands list. But let's decide with tobia if this should be added now or later.

Notice that photometric interpretation can be WhiteIsZero or BlackIsZero that are grays too.

So I suggest to :

  1. Isolate the metadata extraction function utility so we can allow also refresh of this data in the layer properties in the future.
  2. Save the important metadata as they are, not saving aggregated properties like isRGB that was wrongly calculated. In particular you may need to save:
    • samples. I don't know if you need to check if they are 1 byte long. The count should provide the number of "bands" (extra-samples excluded I think).
    • the fileDirectory including PhotometricInterpretation value
    • probably the extra-samples (look at this PR in geotiff.js to see if it is included or not in samples)
  3. From these information, you can desume the "isRGB" information and provide the proper styler.

From my understanding if samples are 1, 3 (or 4, adding the extra one) you may desume the number of "bands" so you can correctly initialize the band selector.
If sample is only 1, it should be gray.
(I asked confirm about this to @dromagnoli ).

@dsuren1
Copy link
Contributor Author

dsuren1 commented Jan 18, 2024

@offtherailz

  • Sometimes it switches to one band randomly

This is because, on Search COG layer from the catalog when the cache is expired, the metadata is not fetched as the operation is restricted to adding the COG layer as a service. This could also result in a projection warning in the catalog as the metadata information holding projection information is missing.

In the future enhancement, the fetch metadata operation can also be performed from layer settings ex: style editor, which should help us handle this case. For now, can I just add a warning message in Style Editor saying The metadata information is missing and hence default to single band editor, this banding could be incorrect. Please add the layer from the catalog by fetching metadata, something like this?

Apart from this, the rest is ready for review. Thanks!

@dsuren1 dsuren1 requested a review from offtherailz January 18, 2024 08:26
@offtherailz offtherailz self-requested a review January 19, 2024 17:07
Copy link
Member

@offtherailz offtherailz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understood that you want to allow min/max source data but editing it in the styler looks uncorrect.

Other stylers allow to edit min/max per band, for instance QGIS

image

I noticed you provided a tooltip to clarify it but it could not be enough. let me take a look at this together with @tdipisa before to see how to proceed.

  • In particular I noticed that these values are anyway applied, even if I deactivate the layer.
screencast-mail.google.com-2024.01.22-11_58_19.webm

I understand the reason but from the user experience this is very confusing.

  • saving whole fileDirectory looks to be potentially an issue. It contains a lot of data that may potentially make the JSON explode (see TileOffsets , TileByteCounts, GeoKeyDirectory). Please fix and save only the data you effectively need, not relying on them.
  • Save the style in a format compatible with other stylers. Here you are storing it as a string, but it should be ajson. Moreover it should be useful to make it consistent with the other style formats.
{ "style": { "body": {
                    "color": ["array",["band",1],["band",2],["band",3],["band",4]]"
                }, "format": "openlayers"
  • please document the raster style in md doc too.

web/client/components/map/openlayers/plugins/COGLayer.js Outdated Show resolved Hide resolved
web/client/plugins/styleeditor/MultiBandEditor.jsx Outdated Show resolved Hide resolved
web/client/plugins/styleeditor/MultiBandEditor.jsx Outdated Show resolved Hide resolved
@offtherailz
Copy link
Member

confirmed the format with @allyoucanmap , let me talk about min and max with tobia.

@tdipisa tdipisa modified the milestones: 2023.02.02, 2024.01.00 Jan 22, 2024
@dsuren1
Copy link
Contributor Author

dsuren1 commented Jan 23, 2024

@offtherailz

  • In particular I noticed that these values are anyway applied, even if I deactivate the layer.

From the video attached, I see the band styling is only disabled, meaning the bands selected from the channels will be ignored but not min and max, as these are independent. Min/max can be cleared if the user chooses to apply only source data values. Additionally, there are cases where only either is needed, for this reason, I have provided an option to disable band styling separately.

  • saving whole fileDirectory looks to be potentially an issue. It contains a lot of data that may potentially make the JSON explode (see TileOffsets , TileByteCounts, GeoKeyDirectory). Please fix and save only the data you effectively need, not relying on them.

My thoughts exactly and I wanted to discuss when PR is reviewed. Glad you noticed. I will add only the PhotometricIntepretation prop for now. The other props can be added later based on the need in the future enhancements

@dsuren1 dsuren1 requested a review from offtherailz January 24, 2024 08:38
@tdipisa tdipisa added the BackportNeeded Commits provided for an issue need to be backported to the milestone's stable branch label Mar 5, 2024
@tdipisa
Copy link
Member

tdipisa commented Mar 11, 2024

@dsuren1 can you please fix conflicts?

@dsuren1
Copy link
Contributor Author

dsuren1 commented Mar 12, 2024

Resolved

@offtherailz
Copy link
Member

I performed the tests on this map:

http://localhost:8081/#/context/COG/46403

Here my findings:

Bugs

  • The stile toggle is enabled, but if I turn off and on, the style do not work.
screencast-mail.google.com-2024.03.14-18_01_02.webm

Things to discuss

It is not easy to review the PR because of this regression not related to the PR (verified also on master):

If I add layers to the map, now I don't have the information for zoom etc.. anymore. Bolivia_LC08_L1TP_001069_20190719_MSf layer do not seems to work on the map, and I have some errors of incompatibility too, when adding layers to the map.
@tdipisa we should scheduele a fix for this.

@tdipisa
Copy link
Member

tdipisa commented Mar 14, 2024

@offtherailz

It is not easy to review the PR because of this regression not related to the PR (verified also on master):

If I add layers to the map, now I don't have the information for zoom etc.. anymore. Bolivia_LC08_L1TP_001069_20190719_MSf layer do not seems to work on the map, and I have some errors of incompatibility too, when adding layers to the map.
@tdipisa we should scheduele a fix for this.

I think it is better if you open a dedicated issue to report the regression you have identified with proper steps to reproduce it, mentioning also if it is affecting only master or also the release.

@offtherailz
Copy link
Member

Here the issue @tdipisa #10072

@dsuren1
Copy link
Contributor Author

dsuren1 commented Mar 19, 2024

@offtherailz @tdipisa

Bugs

  • The stile toggle is enabled, but if I turn off and on, the style do not work.

screencast-mail.google.com-2024.03.14-18_01_02.webm

The problem is caused by missing metadata as explained here

Copy link
Member

@offtherailz offtherailz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are almost in a stable version I think. We have to fix the following:

  • "enableBandStyling" property should not be used, but the style should depend only on the style object. I think the presence of the body.color section is enough to determine if it is enabled or not, but if you need more, add a flag and proper document it.
  • For certain cogs is still unclear to me how to style. For instance this https://cogeo.craig.fr/opendata/ortho/2018_25cm_ain+isere.tif the styler do not look to be working at all. Maybe because of photometryic interpretation : 6 ?

a final note:
Having to save catalogs again and again is counter-intuitive at the end. If we need more metadata, we need to think about a way to update/auto-update layers source metadata.

@dsuren1
Copy link
Contributor Author

dsuren1 commented Mar 21, 2024

@offtherailz

  • "enableBandStyling" property should not be used, but the style should depend only on the style object. I think the presence of the body.color section is enough to determine if it is enabled or not, but if you need more, add a flag and proper document it.

You are right. This prop is not needed. Might have skipped the coffee 😉

At times, the alpha channel may prevent the visualization of certain TIFF sources, and the composition of some TIFF sources may disregard the alpha channel. To mitigate this issue and to eliminate no-data tiles surrounding the image, I have incorporated the nodata attribute into the source (TODO: should made configurable in the future enhancement), which introduces an alpha channel and facilitates the better visualization of the TIFF image.

2018_25cm_ain+isere.tif
image

a final note: Having to save catalogs again and again is counter-intuitive at the end. If we need more metadata, we need to think about a way to update/auto-update layers source metadata.

At least after this change, all the required metadatas are fetched and persisted. But yes, maybe a force fetch metadata option somewhere in the layer settings is needed in the future.

@dsuren1 dsuren1 requested a review from offtherailz March 21, 2024 07:22
Copy link
Member

@tdipisa tdipisa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsuren1

At least after this change, all the required metadatas are fetched and persisted. But yes, maybe a force fetch metadata option somewhere in the layer settings is needed in the future.

I think it might be nice to have it soon, maybe adding a layer refresh button in the toolbar valid for all levels which for COGs also updates the level metadata.

@offtherailz offtherailz merged commit d683b82 into geosolutions-it:master Mar 21, 2024
6 checks passed
@offtherailz
Copy link
Member

@ElenaGallo, could you please test this on DEV ? Thank you

@ElenaGallo
Copy link
Contributor

Test passed, @dsuren1 please backport to 2024.01.xx. Thanks

dsuren1 added a commit to dsuren1/MapStore2 that referenced this pull request Mar 22, 2024
@dsuren1 dsuren1 linked an issue Mar 22, 2024 that may be closed by this pull request
6 tasks
@tdipisa tdipisa removed the BackportNeeded Commits provided for an issue need to be backported to the milestone's stable branch label Mar 22, 2024
offtherailz pushed a commit to offtherailz/MapStore2 that referenced this pull request Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support to multi-band color mapping for COG layers
4 participants